tatanka/client: separate network parts from mesh protocol parts #3176

buck54321 · 2025-02-04T07:20:56Z

Separate the networking logic from the mesh protocol logic by splitting the old TankaClient into two parts. MeshConn handles connections to both tatanka nodes and peers. Mesh handles the client mesh protocol. Mesh is somewhat similar to core.dexConnection in its purpose.

Here's a taste of the separated APIs.

type TheConnectionPart interface {
	ConnectPeer(peerID tanka.PeerID) error
	RequestPeer(peerID tanka.PeerID, msg *msgjson.Message, thing any) (*mj.TankagramResult, error)
	Auth(tatankaID tanka.PeerID) error
	RequestMesh(msg *msgjson.Message, thing any, opts ...RequestOption) error
}

type TheMeshFunPart interface {
	ID() tanka.PeerID
	Next() <-chan any
	Broadcast(topic tanka.Topic, subject tanka.Subject, msgType mj.BroadcastMessageType, thing interface{}) error
	PostBond(bond *tanka.Bond) error
	ActiveBonds() ([]*tanka.Bond, error)
	SubscribeMarket(baseID, quoteID uint32) error
}

Mesh has its own database. That is where things like order info and bonds will be stored. I've implemented a bonds table to demonstrate.

martonp

Definitely makes sense to separate like this.

martonp · 2025-02-12T16:11:28Z

dex/lexi/index.go

+}
+
+// iterate iterates a table or index.
+func (db *DB) iterate(keyPfix keyPrefix, table *Table, io iteratorOpts, isIndex bool, prefixI IndexBucket, f func(*Iter) error, iterOpts ...IterationOption) error {


Suggested change

func (db *DB) iterate(keyPfix keyPrefix, table *Table, io iteratorOpts, isIndex bool, prefixI IndexBucket, f func(*Iter) error, iterOpts ...IterationOption) error {

func (db *DB) iterate(keyPfix keyPrefix, table *Table, defaultOpts iteratorOpts, isIndex bool, prefixI IndexBucket, f func(*Iter) error, iterOpts ...IterationOption) error {

It's a value, so it's copied on the way in. We work on the copy internally, so it wouldn't make sense to name it "default" any more.

martonp · 2025-02-12T16:26:46Z

dex/lexi/table.go

+// UseDefaultIterationOptions sets default options for Iterate.
+func (t *Table) UseDefaultIterationOptions(optss ...IterationOption) {
+	for i := range optss {
+		optss[i](&t.defaultIterationOptions)
+	}
+}


martonp · 2025-02-12T17:39:42Z

tatanka/client/conn/conn.go

+			if err != nil {
+				return err
+			}
+			enc, err := p.encryptRSA(b)


I know this is already existing code, but what's the reason for having a separate RSA key pair in addition to the ECDSA one?

I'm also confused about the signing patterns.

If we just use ws/wss we wouldn't need to sign all messages to prove who sent them, right? wss would encrypt.

If the purpose is to prove to a third party that this message was sent, then we use the signature from the private key of the secp256k1.PublicKey that is unique for every user.

The RSA keypair is for encryption/decryption of p2p messages. This is end-to-end encryption. Server can't read the messages.

If we just use ws/wss we wouldn't need to sign all messages to prove who sent them, right?

Right. For WSS connections, only the initial message needs to be signed now.

Another option worth considering instead of RSA is AES for symmetric encryption. Both peers would use the same key, derived via ECDH using the user’s private key and the counterparty’s public key (e.g., existing secp256k1 keys from DCRDEX identities). This skips a separate key exchange since we’re leveraging keys we already have, and AES is way faster than RSA, microseconds versus milliseconds per message. Here's how to derive an AES key:

func deriveAESKey(privKey *btcec.PrivateKey, peerPubKey *btcec.PublicKey) ([]byte, error) { // ECDH: Compute shared secret sharedX, _ := privKey.ECDH(peerPubKey) sharedSecret := sharedX.Bytes() // x-coordinate (32 bytes) // HKDF: Derive AES-256 key hkdf := hkdf.New(sha256.New, sharedSecret, nil, nil) aesKey := make([]byte, 32) // 256 bits _, err := hkdf.Read(aesKey) if err != nil { return nil, fmt.Errorf("failed to derive AES key: %v", err) } return aesKey, nil }

martonp · 2025-02-12T17:57:18Z

tatanka/client/mesh/mesh.go

+func (m *Mesh) ConnectPeer(peerID tanka.PeerID) error {
+	return m.conn.ConnectPeer(peerID)
+}


Is this only exposed for testing? Looks like right now you connect to a new peer other than the entry node when a message arrives from that peer. When connecting to the entry node, the entry node could share all of its peers.

Uh huh. I'm not certain yet how the server node connection scheme is going to shake out. Will we connect to all the tatanka nodes that we can, or just one at a time and use the others as backups should ours go offline? When we broadcast a message, we should only send it to one, right? How about p2p messaging? Is there some kind of path optimization to be done?

And yes, this is only exposed for testing purposes for right now.

martonp · 2025-02-12T17:59:12Z

tatanka/client/conn/conn.go

+type TatankaSelectionMode string
+
+const (
+	SelectionModeEntryNode TatankaSelectionMode = "EntryNode"


With what kind of request would you only want to message the entry node?

martonp · 2025-02-12T18:36:21Z

tatanka/client/conn/conn.go

+
+// Config is the configuration for the MeshConn.
+type Config struct {
+	EntryNode  *TatankaCredentials


Why only one EntryNode rather than a list?

JoeGruffins · 2025-02-18T08:21:57Z

tatanka/client/conn/conn.go

+	if err := cm.Connect(ctx); err != nil {
+		c.log.Errorf("error connecting to tatanka node %s at %s: %v. will keep trying to connect", err)
+	}


If there is an error that would be returned from the websocket the ctx is canceled and this won't keep trying I think.

Yeah. We'll have to look into reconnect handling too.

JoeGruffins · 2025-02-18T08:29:47Z

tatanka/client/conn/conn.go

+		for peerID, tt := range c.tatankaNodes {
+			if tt.cm.On() && peerID != skipID {
+				tts = append(tts, tt)
+			}
+		}


Can return earlier if Any.

JoeGruffins · 2025-02-18T09:07:03Z

tatanka/client/conn/conn.go

+			if err != nil {
+				return err
+			}
+			enc, err := p.encryptRSA(b)


I'm also confused about the signing patterns.

If we just use ws/wss we wouldn't need to sign all messages to prove who sent them, right? wss would encrypt.

If the purpose is to prove to a third party that this message was sent, then we use the signature from the private key of the secp256k1.PublicKey that is unique for every user.

JoeGruffins · 2025-02-19T05:12:17Z

tatanka/client/conn/conn.go

+		c.handlers.HandleTatankaNotification(tatankaID, msg)
+		return nil
+	default:
+		c.log.Errorf("tatanka node %s send a message with an unhandleable type %d", msg.Type)


Suggested change

c.log.Errorf("tatanka node %s send a message with an unhandleable type %d", msg.Type)

c.log.Errorf("tatanka node %s send a message with an unhandleable type %d", tt.peerID, msg.Type)

martonp · 2025-03-01T16:08:59Z

I’ve updated the encryption to use AES instead of RSA in this diff: 03c89e7

It retains the connection request to establish an ephemeral key pair for each peer connection. This ensures that if a permanent private key leaks, past and future communications remain secure due to the ephemeral keys.

I suggest adding a typed TankagramResultPayload with an error message field. This would allow peers to signal issues—like when one restarts, loses its ephemeral key pair, and the counterparty tries to use the old pair. I held off on implementing this to minimize merge conflicts for now.

Separate the networking logic from the mesh protocol logic by splitting the old TankaClient into two parts. MeshConn handles connections to both tatanka nodes and peers. Mesh handles the client mesh protocol. Mesh has its own database. That is where things like order info and bonds will be stored.

buck54321 changed the title ~~tatanka: separate network parts from mesh protocol parts~~ tatanka/client: separate network parts from mesh protocol parts Feb 4, 2025

martonp reviewed Feb 12, 2025

View reviewed changes

JoeGruffins reviewed Feb 18, 2025

View reviewed changes

JoeGruffins mentioned this pull request Feb 20, 2025

tatanka: Add orderbook map #3194

Draft

buck54321 force-pushed the meshconn branch from 59589d4 to 6b00b74 Compare February 20, 2025 11:13

JoeGruffins reviewed Feb 26, 2025

View reviewed changes

buck54321 added 3 commits March 2, 2025 22:02

review followup

cf2ed1b

fix missing arg in error log

1577b6d

buck54321 force-pushed the meshconn branch from 6b00b74 to 1577b6d Compare March 3, 2025 13:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tatanka/client: separate network parts from mesh protocol parts #3176

tatanka/client: separate network parts from mesh protocol parts #3176

buck54321 commented Feb 4, 2025

martonp left a comment

martonp Feb 12, 2025

buck54321 Feb 20, 2025

martonp Feb 12, 2025

martonp Feb 12, 2025

JoeGruffins Feb 18, 2025 •

edited

Loading

buck54321 Feb 20, 2025 •

edited

Loading

martonp Feb 25, 2025

martonp Feb 12, 2025

buck54321 Feb 20, 2025

martonp Feb 12, 2025

martonp Feb 12, 2025

JoeGruffins Feb 18, 2025

buck54321 Feb 20, 2025

JoeGruffins Feb 18, 2025

JoeGruffins Feb 18, 2025 •

edited

Loading

JoeGruffins Feb 19, 2025

martonp commented Mar 1, 2025

	func (db DB) iterate(keyPfix keyPrefix, table Table, io iteratorOpts, isIndex bool, prefixI IndexBucket, f func(*Iter) error, iterOpts ...IterationOption) error {
	func (db DB) iterate(keyPfix keyPrefix, table Table, defaultOpts iteratorOpts, isIndex bool, prefixI IndexBucket, f func(*Iter) error, iterOpts ...IterationOption) error {

	c.log.Errorf("tatanka node %s send a message with an unhandleable type %d", msg.Type)
	c.log.Errorf("tatanka node %s send a message with an unhandleable type %d", tt.peerID, msg.Type)

tatanka/client: separate network parts from mesh protocol parts #3176

Are you sure you want to change the base?

tatanka/client: separate network parts from mesh protocol parts #3176

Conversation

buck54321 commented Feb 4, 2025

martonp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JoeGruffins Feb 18, 2025 • edited Loading

Choose a reason for hiding this comment

buck54321 Feb 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JoeGruffins Feb 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martonp commented Mar 1, 2025

JoeGruffins Feb 18, 2025 •

edited

Loading

buck54321 Feb 20, 2025 •

edited

Loading

JoeGruffins Feb 18, 2025 •

edited

Loading